We built this system in modules over the duration of the project. Each week we worked on a different subsystem before merging it to the master system at the end of that week of development. This enabled better time management and also version control incase one of the modules proved faulty upon integration.
OBDII BLE Scanner: The first module we worked on was the OBDII scanner itself. The install of the necessary software was relatively straightforward with no issues. The bluetooth connection was more difficlut to set up, but both the OBD install and BLE connection setup can be found in the github repository here.
Graphical User Interface: The second module we worked on was the touchscreen and default status screen. With knowledge of pygame from the labs, we decided to stick with it to implement our graphics and touch interactivity. Pygame is a set of Python modules for video game development. It is free to download and runs on most platforms and operating systems. Pygame comes preinstalled on Raspbian, however if needed, the install info can be found here. Ryan ran into issues getting started with the Raspberry Pi because he did not have a keyboard or monitor, only his laptop. After borrowing a roommates keyboard and configuring connection to wifi according to this guide, the connection to the pi over the home wifi proved incredibly slow when using ssh. Given this, a VNC was setup using the program VNC Viewer and then connecting the pi to the home network directly via an ethernet cable. This Raspberry Pi configuration page as well as this youtube guide proved helpful in establishing the setup. In setting up the screen module itself, it required a few added lines to config.txt which is outline by the product page here. While this worked for the display functionality, we ran into issues with the touchscreen. In an attempt to use fbcon, as we had in lab during the semester, the screen registered touch but the data did not correspond to the correct location on the screen. Eventually, we found a solution by starting X11 for a single application as this guide details. By adding
startx --kiosk --
to .bashrc, the touchscreen properly worked. Another issue we faced was specific to the RPM gauge. When using pygame to rotate the needle we ran into two problems. The first was if you do not specifically set the alpha values of a surface, in our case the rect for the needle, when rotating any amount that is not a multiple of 90, pygame adds a padding to the rect which essentially makes it a large square of color instead of a thin needle. We fixed that by using pygame.SRCALPHA in creating the needle surface.
self.__needle = pygame.Surface((radius // 32, radius), pygame.SRCALPHA)
The second issue occured when rotating more than 0-90 degrees. When doing so, the rect would no longer be centered on the gauge. We fixed this by recognizing that the rect’s previous left and top was no longer the new left and top so we had to adjust the needle postion by either the width, height, or both of the rect depending on what desired rotation was and what quadrant it fell into. For example, if the rotation angle fell in the third quadrant (180 - 270) where 0 is directly pointing down from the center of the rpm gauge, the left was set to center of the rpm gauge less the width of the needle rect, and the top was set to center of the rpm gauge less the height of the needle rectangle. Note, we used a png file for the RPM gauge background which can be found here.
elif self.__needle_angle < 180 and self.__needle_angle ≥ 270:
screen.blit(rot_needle, (x - rot_needle.get_width(), y - rot_needle.get_height()))
And the end of testing, the default status display upon power on looked as shown below:
Figure 5: Picture of the final status screen
Dashcam: The third module we worked on was the dashcam. We decided to use the piCamera library with the project since it comes preinstalled with Raspbian. We created a live feed by using a preview that essentially hijacked the framebuffer to overlay the camera feed on our pygame GUI. When the dashcam menu button was pressed the preview window was shown and when the user navigated away from the dashcam menu button it was hidden. While viewing the dashcam feed, the user could elect to press a record button that was enabled through pygame. When pressed, it would begin saving a video file in one minute increments, within a folder that was labeled with the time stamp at the press of record. The reason one minute increments were used was to enable error checking. The pi is only capable of checking if there was a successful recording when the recording is saved to file, and so by recording in one minute increments, the system is able to check every minute if there was an error or not. The picamera library has a macro that enables cutting of video which made this an easy implementation. When the user desires to stop the recording, they press the stop button enabled through pygame and the latest one minute recording is stopped and saved. The user may then access the video files by removing the miniSD card from the pi and placing in a computer. One bug we encountered with the record functionality was that when a user had pressed record then subsequently navigated to another tab and then returned to the dashcam tab, the record button would reappear despite the device actively recording. We tracked this bug to a line of code that reset a recording flag whenever the user navigated to the dashcam page. By removing the line prompting the flag change the bug was resolved. The finished dashcam page looked as shown below:
Figure 6: Picture of the final dashcam appearance
Example dashcam clip downloaded from the system post drive
LINK
GPS: The GPS module was the last piece of the project to arrive due to COVID-19 related logistic delays. To use the GPS unit, we installed gpsd a daemon specially designed for gps and commonly used on Unix-like software, its documentation can be found here. To install we simply ran:
sudo apt-get install gpsd
To then use the daemon we installed a corresponding python library through:
pip install gpsd --user
The user option was added so that the install would be constrained to the active user and not the enitre system. We then worked on implementing a dummy test system so that when the GPS module arrived we would be able to take the data sent from the GPS and plug it into the already built module. The project had orginally hoped to use Open Street Maps to pull and render our own slippy map, but after diving deeper into the steps that would be required to bring this to life we realized that it was out of scope for our remaining time line. We instead chose to pull a screenshot of an Arizona neighborhood that was large enough to demonstrate the feasibility of our system. To do so we navigated to the export tab of the open street map site here. We then were able to specify the bounds that we wanted for the tile and then download the specified region as an image. We used pygame to display this map "tile" and then used a small dot to represent the cars location. By mapping a linear function between the number of pixels on the screen and the longitude and latitude bounds of the tile, we were able to take an input of longitude and latitude from the GPS and convert it to pixel values to change the location of the dot representing the car's location. The system was implemented in such a way that theoretically, if we had taken a series of map images or "tiles" and linked their respective longitude and latitude bounds, that when the system approached the bounds of a tile, the system could have changed the background tile and the function relating pixels to the new bounds. This would still not be a final solution however. To implement a navigation system that appeared as if the map was scrolling and not incrementally shifting, it would have required more time and back end then our remaining timeline allowed. Our final GPS screen appeared as show below:
Figure 7: Picture of the final GPS screen appearance (red dot marks current location)
